1. Field of the Invention
The present invention is in the fields of electronics, and in particular control engineering, and more particularly concerns the field of medical imaging apparatuses, for example magnetic resonance tomography systems, computed tomography systems, lithotripters, and other complex medical technology apparatuses.
2. Description of the Prior Art
Medical technology apparatuses embody a number of technical sub-systems, for example a C-arm, a patient table (controllable and movable via a corresponding motor), collimators and dose measurement systems, as well as corresponding actuators (for example to move the patient table) with corresponding position sensors (for example rotary encoders and cables).
The operation of a particular medical technology apparatus requires a number of different workflows to be executed. The individual technical sub-systems must be configured for their embedding or integration into the apparatus (as embedded systems). Furthermore, the individual control elements or actuators of the technical sub-systems must be configured and controlled accordingly. After a configuration phase, the operation of the medical technology apparatus can be started. The operating state is typically detected continuously, and monitoring of the technical sub-systems is implemented. Moreover, tests (concerning the apparatus and the technical sub-systems) can also be executed.
For both the configuration and the operation of the technical sub-systems and of the complex complete system, it is necessary that the properties of the sub-systems (also called “components” or “modules”) be made known to the complete system.
Conventionally, such imparting of the component properties takes place in the form of a data sheet that is delivered by the manufacturer of the component. This data sheet is then received by the system developer and implemented in software, normally individually for each component. The data sheet can exist beforehand in various formats, for example as a design specification or Excel sheet. Some protocols (such as CANopen) also stipulate a conditional, machine-readable data sheet in a separate format. The data sheet is thereby normally not stored in the system (memory). A disadvantage of the use of such a data sheet is, that it describes only the properties of the component, for example the register assignment. The task of the system software developer is then to retrieve from this specification (and possibly in cooperation with the developer or vendor of the component) the information that is necessary in order to configure and operate the apparatus in the complete system. This process is iterative and is very susceptible to misunderstandings and errors.